cudaPackages: enable cross-compilation (take two)#279952
cudaPackages: enable cross-compilation (take two)#279952ConnorBaker wants to merge 34 commits intoNixOS:masterfrom
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
e371d54 to
a2d5dcc
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
7b5683f to
5a9d2c8
Compare
5a9d2c8 to
ecb9e96
Compare
There was a problem hiding this comment.
TODO @ConnorBaker
Are these correct? Do we need to use a spliced version? Unclear whether makeSetupHook does anything on the backend to draw these from buildPackages (pkgsBuildHost) or uses the default pkgs (pkgsHostTarget).
There was a problem hiding this comment.
- Thinking locally, yes they should be spliced. The hook is going to reside in the target derivation's
nativeBuildInputs, so with splicing I expect the hook to be taken from thebuildPackages. I expect thebackendStdenvfrom that splice to contain a compiler forbuild->buildinstead ofbuild->host. - Thinking more globally, there are just so many places where we already hard-code the
ccat evaluation/rendering time:setupCudaHook,nvcc,backendStdenv. This wrong, redundant, complex, and we better choose just one place
There was a problem hiding this comment.
We should use the current host's compiler. Then we take the hook from the BuildHost slice, so its "host" is really our "build"
|
@yannham current blockers are these: Building Fixing that error (either by commenting it out temporarily or inserting Unclear whether we're sourcing compilers from the correct package sets in #279952 (comment) and #279952 (comment). |
That's a regression after the cuda12 fixes then, and we should PR a fix separately. I thought we'd just update the manifest generator and remove these |
There was a problem hiding this comment.
Why? I think we generally want the host system's binaries, except when we handle lib/ and nvvm/lib/ in nvcc (then we do want target)
This comment was marked as outdated.
This comment was marked as outdated.
2dbe0a5 to
2525205
Compare
This comment was marked as outdated.
This comment was marked as outdated.
|
TODO(@ConnorBaker): NVCC, as well as any dependency which finds itself in Likely for ease of implementation, NVCC is used as a way to inject dependencies on setup hooks. If that's the case, it falls apart when cross-compiling, as our setup hooks need to be able to run on the build platform rather than the host/target. |
Since, even under cross-compilation, we evaluate this flag on multiple platforms, it makes more sense to move the platform check out of the throw condition and into the boolean return value. The alternative is to restrict all uses of this value to locations which gaurd evaluation so it does not occur when the host platform is still x86_64.
…body like other setup hooks
1a9f28b to
1ac7621
Compare
…nable structuredAttrs
|
Closing as this PR is largely superseded by #301416. |
Important
This PR includes changes which have not yet been merged into
master. It should not be merged prior to them:stagingand must be merged intomasterbefore merging.Description of changes
#275560 brings in a bunch of additional work that I thought needed to be coupled with support for cross-compilation, but over the break I decided to revisit this. Maybe it doesn't need to be coupled -- this is a second attempt at enabled cross-compilation for cudaPackages.
Of note, both
cuda-modules/setup-hooks/extension.nixandcuda-modules/cuda/overrides.nixhave been refactored. They are now attribute sets of functions which are invoked withcallPackageto create setup hooks and package overrides, respectively. The move to usingfinal.callPackagerather than retrieving required packages directly fromfinalallows us to use the__splicedattribute on derivations when cross-compiling to ensure we're selecting the correct version of a package.When adding packages to
nativeBuildInputsorbuildInputs, splicing (largely) happens automatically. That is, there is no need to manually specify which splice a package should be drawn from. Additionally, the default package set thecallPackagearguments are drawn from,pkgs(akapkgsHostTarget), helps minimize breakage. However, there are places where we do need to specify the splice to use:pkgs(which is to saypkgsHostTarget).nativeBuildInputsinpre/postphases should be spliced so the correct package is made available.nativeBuildInputsin a*Flags-style argument should be spliced, again to ensure the correct package is made available and that the default (pkgs) splice isn't used instead.Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.